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ABSTRACT 



A telecommunication management system is provided for 
managing hardware and software systems within a telecom- 
munication network. The management system includes an 
Operator Services component, a Management Services com- 
ponent and an External Interfaces component. The Operator 
Services Component provides a user interface between one 
or more operators and the remainder of the system's pro- 
cesses. The Management Services Components provides 
servers which function as an interim stage of information 
transmittal between the operators and the external interfaces. 
The External Interfaces provide interfacing between net- 
work devices and the management system's operators by 
way of the Management Services component. The manage- 
ment system, for example, can efficiently manage a group of 
integrated receiver/decoders grouped together according to a 
satellite circuit. 

20 Claims, 13 Drawing Sheets 
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SYSTEM AND METHOD FOR MANAGING to direct commands from one PC as opposed to another. For 

HARDWARE TO CONTROL TRANSMISSION example, the program command could not be sent at the 

AND RECEPTION OF VIDEO BROADCASTS same time that other IRD commands were being transmitted. 

Thus, the code switch was necessary to control which PC 

BACKGROUND OF THE INVENTION 5 could actually transmit a command over the satellite net- 

. work at a given time. Another problem was that the Paradox 

1. Field Of The Invention database lacked referential integrity. For example, informa- 
This invention generally relates to telecommunications t j on relating to a particular IRD could be removed from the 

systems and, more particularly, to a system and method for Paradox database without warning of an integrity violation, 

managing hardware and software processes to control Trans- 10 Further, only selected information was maintained in the 

mission and reception of video broadcasts. Paradox database. The information structure was inflexible 

2. Background and IRDs could not be classified according to their current 
Systems for the transmission and reception of the video state (e.g., authorized, de-authorized, sold, etc.). Another 

broadcasts are generally known. Video broadcasts are typi- drawback related to management reports, which had to be 
cally transmitted from a broadcast site to a reception site by ^ prepared manually. Also, audit trails of worked performed 
way of a satellite link or relay. The broadcast site typically ( e -g*> commands sent, IRDs authorized, etc.) were nonex- 
broadcasts a particular program by sending an electronic ktent. Further, system functions were not based upon user 
signal to a particular satellite which services the reception IDs or functional roles. Therefore, system security was 
site. The electronic signal can comprise both video and data limited. Moreover, a control operator could not group corn- 
information. The electronic signal may be received from the 20 mands and execute them as a single command to, for 
satellite by an integrated receiver/decoder ("IRD") located at example, one or more of the IRDs. The operator did not have 
the reception site. the ability to schedule commands for execution or to sched- 
The reception site typically services one or more sub- "^ changes to the program command. Among other 
scribers which are linked to the reception site by a suitable P roblems ' drawbacks resulted in tune-consuming and 
transmission medium. The transmission medium can be, for 25 c™Uon °f broadcast schedules. For exampje it 
example, coaxial cable, optical fiber or a combination of was n ° l <«>common that four days were required to build a 
both. Once the signal has been received at the reception site mo "' hl y broadcast schedule for a s.ngle customer Other 
from the satellite, it is forwarded to one or more of the P roblems ^ P nor telecommun.cation systems are known 
subscribers. t0 eMSl - 

30 

Typically, both video and data information are transmitted SUMMARY OF THE INVENTION 

from the broadcast site to the reception site. The data . „ , . 

formation may include decryption information used by the " 15 aa ob J ect of the P resent invention to provide a 

IRD to determine if the IRD is eligible to receive the video telecommunication management system in which changes to 

information being transmitted. The IRD compares the „ components, such as a group of integrated 

decryption information it receives with decryption keys 35 receiver/decoders, can be made by execution of a single 

previously stored in its memory. If a match occurs, the IRD command or macro. 

will decrypt the video information and transmit a decoded It is a further object of the present invention to provide a 

signal to one or more designated subscribers. telecommunication management system which operates in a 

A typical IRD contains 32 physical slots capable of 40 |*»™d-dala environment. Data is maintained and updated at 
storing decryption keys. This means an IRD can receive 1 of both a svstem database and at svstem nodes * 
32 possible broadcasts based upon the decryption keys it 11 15 a further object of the present invention to provide a 
uses to decrypt the video transmission. Also, the IRD can be telecommunication management system, the operation of 
configured to receive a program command which instructs which is at least partially automated, 
the IRD as to which slot to use to obtain the decryption keys 45 It is a further object of the present invention to provide a 
needed to decrypt a particular video broadcast. By changing telecommunication management system in which com- 
this program command to designate a different slot, the IRD mands being sent to one or more telecommunications net- 
can be tuned to a different frequency to receive a different work devices can be grouped together for execution at a 
video broadcast. single time. 

Telecommunication systems of the foregoing type suffer 50 It is a further object of the present invention to provide a 

from several drawbacks. Such systems do not provide the telecommunication management system having multiple 

ability to easily load decryption keys into IRD slots. Also, components and processes which are fully integrated and 

such systems do not allow an operator to quickly change the scalable. 

broadcast being received by an IRD by way of altering the To solve these and other objects of the invention and to 

program command. In the past, IRDs have been controlled 55 overcome the drawbacks of prior telecommunication 

by a personal computer ("PC")-based system. One such systems, a telecommunication system is provided. The sys- 

system used a Paradox database to store management infor- tem includes a broadcast site having a transmitter for trans- 

mation. The entire system ran on PCs in an MS Windows mitting a signal and an encoder for encoding the transmitted 

environment. However, four PCs were needed to run the signal. The system has a plurality of reception sites, each 

entire system and each PC was dedicated to a distinct 60 having at least one integrated receiver/decoder. The system 

component of the system. Therefore, a system operator also has a satellite for relaying the signal from the broadcast 

would have to move from one PC to another depending on site to each of the plurality of reception sites. The system 

the task he or she wished to perform. Also, the PCs were not also includes a management system. The management sys- 

networked together. If one PC crashed, then that part of the tem includes a plurality of processes, the processes being 

system was unavailable for use until the PC was replaced or 65 integrated for managing one another and for managing the 

repaired. Thus, the system was "single-threaded." Because encoder and the plurabty of integrated receiver/decoders, 

the system was not integrated, a code switch was necessary Each of the integrated receive/decoders is assigned to at 
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least one of a plurality of satellite circuits. The management FIG. 19 is a block diagram representing the interfacing 

of the encoder and the plurality of integrated receiver/ between a process of the management system of FIG. 2 and 

decoders is accomplished by using the management system the remainder of the management system of FIG. 2. 
to manage the plurality of satellite circuits. 

Further objects, features and advantages of the present 5 
invention will be understood by those having ordinary skill 

in the pertinent art by reviewing the detailed description of A telecommunication management system is provided for 

the preferred embodiments in connection with the appropri- transmitting and receiving video broadcasts. The manage - 

ate figures. ment system allows flexibility in changing the parameters of 

10 one or more characteristics associated with various hardware 
devices of the system. The system also allows flexibility and 
FIG. 1 is a block diagram representing a telecommuni- scalability in the different system components and pro- 
cation network according to an embodiment of the present cesses. As shown in FIG. 1, a telecommunication network 
invention. includes a broadcast site 10 for transmitting a program 
FIG. 2 is a block diagram representing a management 15 si S nal 10 a reception site 30. The signal is relayed from 
system of the telecommunication network of FIG. 1. broadcast site 10 to reception site 30 by a satellite 20. The 

FIG. 3 is a block diagram representing the interfacing si e nal .[ s P as f d u fr ° m the ^P* 00 si * 10 a P lurali ^ ° f 

between a process of the management system of FIG. 2 and subscribers 50, which are each linked to the reception site by 

the remainder of the management system of FIG. 2. 20 a smtabl ° transmission medium (e.g., coaxial cable, optical 

a • m i a- r *u ' t f ~ ° fiber or both). 

FIG. 4 is a block diagram representing the interfacing « 

between a process of the management system of FIG. 2 and P» sl S nal preferably comprises both video information 

the remainder of the management system of FIG. 2. and data information and is generated by a program source 

* . li i j- *t_ ■ , r • 11- Preferably, the signal passes from program source 11 to 

FIG. 5 is a block diagram representing the interfacing , ,v i_- u » ,i_ -j • c 

, A - t , 6 * * r T-i 'i j an encoder 14, which encrypts the video information of the 

between a process of the management system of FIG. 2 and 25 c , tA . Vi a * *t • *• 

t , .j c . * . * mr^ 1 program. Encoder 14 is linked to a telecommunication 

the remainder of the management system of FIG. 2. r 6 An n c , , Afl 

to J management system 40. Preferably, management system 40 

FIG. 6 is a block diagram representing the interfacing ^ lmked tQ a pluralily of broadcast sites 10 m a similar 

between a process of the management system of FIG. 2 and maQner ^ sigQal from encodef u ^ then passed lQ a 

the remainder of the management system of FIG. 2. transmitter 13, which transmits the signal to satellite 20. The 

FIG. 7 is a block diagram representing the interfacing 30 broadcast site 10 is linked to management system 40 through 

between a process of the management system of FIG. 2 and a suitable interface. The operator can send program com- 

the remainder of the management system of FIG. 2. mands to the encoder to modify the data information being 

FIG. 8 is a block diagram representing the interfacing transmitted to the reception site. The program commands 

between a process of the management system of FIG. 2 and 35 may be forwarded to any of the devices within the network, 

the remainder of the management system of FIG. 2. xh e reception site 30 includes an integrated receiver/ 

FIG. 9 is a block diagram representing the interfacing decoder ("IRD") 31. IRD 31 is capable of receiving and 

between a process of the management system of FIG. 2 and reading 3 both the video and data information contained in 

the remainder of the management system of FIG. 2. the program signal being relayed by satellite 20. IRD 31 

FIG. 10 is a block diagram representing the interfacing 40 includes a number of slots (preferably 32), each of which is 

between a process of the management system of FIG. 2 and capable of receiving and storing a set of preset decryption 

the remainder of the management system of FIG. 2. keys. Preferably, the data portion of the program signal 

FIG. 11 is a block diagram representing the interfacing includes a set of encryption information. The encryption 

between a process of the management system of FIG. 2 and information determines which decryption keys are necessary 

the remainder of the management system of FIG. 2. 45 10 decrypt the encrypted video portion of the program signal. 

FIG. 12 is a block diagram representing the interfacing l RD 3 * » ca P ab ! e of reading the encryption information 

between a process of the management system of FIG. 2 and from the data formation, and is further capable of com- 

the remainder of the management system of FIG. 2. P ann f . the encryption information to the decryption keys 

™„ . • . c • stored in each of its slots. If this comparison results in a 

FIG. 13 .s a block d.agram representmg the mterfac.ng match ^ IRD ^ enab)ed tQ receive ^ d ^ ^ 

between a process ot the management system oll-lb. 1 and - MomttSou of the _ roeram sienaL ^ 

signal is 

the remainder of the management system of FIG. 2. tU , . , _T . . *u i r. r 

& J then passed via other known components to the plurabty of 

FIG. 14 is a block diagram representing the interfacing subscribers linked to the reception site, 

between a process of the management system of FIG. 2 and « f U1 tU . , . , , . 1% c ir>i^ ?i 

, • j r l c t^t^, „ Preferably, the network includes a plurality of IRDs 31, 

the remainder of the management system of FIG. 2. , . . , . , . t . -\ ^ A ^ 

to 3 55 which are located m one or more reception sites 30. One or 

FIG. 15 is a block diagram representing the interfacing morc of lhc p i ura ii ly of i RDs 31 m assigned to a common 

between a process of the management system of FIG. 2 and satdlite circuil ^ satdlite circuit ^ an mtegrated group of 

the remainder of the management system of FIG. 2. IRDs represents a common link between the circuit 

FIG. 16 is a block diagram representing the interfacing IRDs and an operator of management system 40. As dis- 

between a process of the management system of FIG. 2 and 60 cussed above, a system operator can send a program com- 

the remainder of the management system of FIG. 2. m and to encoder 14. The program command changes the 

FIG. 17 is a block diagram representing the interfacing configuration of the satellite network. This change results in 

between a process of the management system of FIG. 2 and a corresponding change in the configuration of each IRD 

the remainder of the management system of FIG. 2. assigned to the satellite circuit. 

FIG. 18 is a block diagram representing the interfacing 65 The program command is a data-driven command which 

between a process of the management system of FIG. 2 and is capable of initiating one or more of a variety of functions 

the remainder of the management system of FIG. 2. by changing the parameters of the satellite circuit. 
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Preferably, these functions include changing an existing set 
of decryption keys, adding a new set of decryption keys, 
authorizing a new service, authorizing a new broadcast, 
dcauthorizing a service or broadcast, making an authoriza- 
tion or deauthorization temporary, assigning an IRD to the 
satellite circuit, deleting an IRD from the satellite circuit. 
Therefore, the program command affects one or more char- 
acteristics of the network configuration. Program commands 
which affect IRD functions are sent to the IRDs by an 
encoder or group of encoders. 

Preferably, the program command includes one or more 
pieces of data from a database. The database should be 
configured to allow the management system 40 to operate on 
a shared -data basis. That is, data may be shared between the 
system operator's workstation, other user workstations, the 
various management system servers and the database. Per- 
sistent data should reside in the database, but should be 
accessible by the workstations and the local server. 
Preferably, changes to the data which are entered at one of 
the workstations automatically trigger corresponding 
updates to the shared data located at other workstations, the 
system servers and the database. Similarly, changes made by 
users should automatically trigger corresponding updates to 
other workstations and the database. For example, when a 
program command is executed, relevant audit information is 
automatically saved in the database so that it may later be 
accessed by an operator. Also, changes to client information 
are automatically saved. Preferably, the database is config- 
ured so that all initial information and any changes thereto 
are structured in such a manner as to allow reports of such 
information to be automatically generated. The database 
may be, for example, an Oracle database. 

I. Management System Overview 

Management system 40 will now be described in greater 
detail. The telecommunication management system provides 
a means for managing a broadcast network. The network is 
generally responsible for performing video compression and 
satellite transmission of video broadcasts. In particular, the 
management system helps manage a network of devices 
including integrated receiver/decoder (IRD) equipment that 
are used to receive satellite transmissions at various sites 
within the network. The management system provides at 
least the following capabilities: (1) provides new customers 
and customer equipment (IRDs); (2) authorizes and installs 
IRDs on the networks; (3) sends commands to specific IRDs 
on the network; (4) transmits and manages a program data 
stream ("PDS") to allow IRDs to receive a video broadcast. 
Preferably, customer and IRD information is maintained in 
an central database (e.g., an Oracle database). Various 
reports can be generated from the data in this database. 
Additionally, a series of administrative editors provides an 
ability to maintain a system configuration which is data- 
specific to each customer. 

With respect to hardware and software processes, the 
management system preferably operates in an environment 
employing a distributed architecture. In this environment, 
devices responsible for event processing are physically 
separated from those providing user interface facilities. 

Preferably, the management system is an object-oriented 
software system as implemented using SNAP™ and the C 
programming language. SNAP™ is a Strategic Networked 
Application Platform and is available, for example, from 
Template Software™. The application architecture should 
be highly distributed. The major components of the appli- 
cation architecture are shown in FIG. 2, in which boxes 
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represent physical processes and significant process mod- 
ules. For convenience, only the principal inter-process com- 
munication links are shown in FIG. 2. Greater detail regard- 
ing the interfacing of the various components and processes 

5 is provided below. 

The management system preferably uses a multi-process 
approach in order to design for scalability. Each process is 
responsible for a distinct functional area of the system and 
multiple copies of most processes can be deployed in order 

10 to increase the system performance. 

The management system processes use efficient interpro- 
cess communication techniques to exchange information. 
Interprocess communication may be implemented, for 
example, via remote procedure calls via a Shared Informa- 

15 tion Base ("SIB"). SIB is a bundled feature of SNAP which 
provides the ability to broadcast changes to shared data to 
registered client processes. Selected system data is kept in 
both the system database and on the system servers. Pro- 
cesses on user workstations can use interprocess communi- 

20 cation to access both main memory and disk-based data. 
The major processes of the management system applica- 
tion are each located within cone of three components. The 
first component, Operator Services, provides a layer of user 

25 visibility and access into the second component, Manage- 
ment Services. The Operator Services component provides 
such services as user log-in, network mapping, site control, 
message windows, reports generation, administrative tools, 
process manager, and alarm window. Each user on the 

30 system has its own copy of the Operator Services component 
software and hardware. The second component is Manage- 
ment Services, which supports the management system as a 
whole. This component provides security control, alarm 
routing and application infrastructure on behalf of all system 

35 users. The third component is External Interfaces and is 
responsible for communicating directly with external sys- 
tems and devices. This component includes a number of 
interfaces that receive and format raw data for analysis as 
well as attaching necessary communication protocols to 

4Q outbound transactions going to the external systems and 
devices. In addition to these three major components, the 
management system uses one or more logical databases to 
provide persistent data storage of application data as well as 
system configuration data. 

45 II. Operator Services 

The Operator Services component will now be described 
in greater detail. As discussed above, the Operator Services 
component provides such functions as user log-in, network 

50 mapping, site control, message windows, reports generation, 
administrative tools, process manager and alarm window. Its 
major associated processes include at Top Level Menu 
process, Network Mapping process, a Site Control process, 
and a Process Manager process. The Site Control process 

55 includes an IRD Management process, Site Management 
process, Command process, Macro process, SCP process, 
and PDS Manager process. For clarity, however, each of the 
processes included in the Site Control process will be 
discussed separately. 

60 The Top Level Menu encompasses user login, adminis- 
trative tools, user interfaces including an interface for gen- 
erating reports, and message windows. The Top Level Menu 
process collects and verifies a user's ID and password 
information, as well as functional role information and 

65 displays the various menu options available within the 
Operator Services component. It also initiates the start-up of 
a set of user interface processes via a Process Monitor, 



06/23/2004, EAST Version: 1.4.1 



6,160, 

7 

invokes user windows associated with these processes, and 
requests termination of the processes upon shutdown of the 
management system. The Top Level Menu process also 
includes administrative tools editors for configuring system 
operator and network default information, and supports the 5 
user interface related to the generation of management 
system reports. 

With respect to logging in, the Top Level Menu process is 
the only means by which an operator may gain access to the 
services provided by the rest of the management system. The ™ 
user ID and password are collected from the user and passed 
to an Authentication Server for validation. Only those 
windows, menu entries, and other associated interfaces 
specifically permitted for the particular user are enabled. 

The interfacing of the Top Level Menu process with the 15 
remainder of the management system is shown in greater 
detail in FIG. 3. The top level menu process connects to a 
Process Monitor process to register, to invoke other user 
interface processes, to invoke windows within other user 
interface processes, and to shut down all related user inter- 20 
face processes when a user logs out. 

The Top Level Menu process also connects to an Authen- 
tication Server process to verify user IDs and password 
information, and to gather a list of user-specific privileges. 
These two processes are also connected whenever a request 25 
is made for maintenance on user or operator rule information 
by way of an administrative tool's access control option. 

The Top Level Menu process also connects to a Message 
Dispatcher process by way of an informational message 3Q 
window. Messages are automatically forwarded from the 
Message Dispatcher to the informational message window 
using a SNAP™ shared information base ("SIB") Autoget 
dispatching facility when a user logs into the system. Mes- 
sages can be originated by external systems within the 35 
overall telecommunications network as well as by the pro- 
cesses and components of the management system itself. 

The Top Level Menu process also connects to a Configu- 
ration Server to request information such as networks and 
encoders currently controlled by the management system. 40 
Other information received from the Configuration Server 
includes network-specific key indices, channel and program 
tier mask ("PTM") default information. Updates to these 
objects may be performed through this connection. 

The Top Level Menu process also interfaces with a system 45 
database reports facility anytime a request for a report is 
generated. Depending upon the request, a return request may 
be provided to the user soliciting further information such as 
report criteria or parameters. Once the reporting criteria is 
specified, the report is generated as a system command 50 
invoking the reports facility. 

Another process within the Operator Services component 
is the Network Mapping process. This process graphically 
displays information about the entire telecommunication 
network. Preferably, information is available at different 55 
levels, including network, regional, site and device levels. 
Information should be displayed in a view-only mode as the 
Network Mapping process preferably serves only as a net- 
work navigational tool. When regional information is 
displayed, an operator can view information regarding sites 60 
in a particular region. Selecting a site allows an operator to 
display information regarding the devices at a particular site. 
For example, the operator can display a list of authorized 
IRDs at a particular site. The information can be configured 
to various formats. For example, the Network Mapping 65 
process can be configured to display IRD serial numbers as 
well as the channel to which an IRD is tuned. 
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The interfacing between the Network Mapping process 
and the remainder of the management system is shown in 
greater detail in FIG. 4. Preferably, the Network Mapping 
process registers itself and any of its associated windows 
with the Process Monitor. The Process Monitor can process 
requests to show network map windows and to shut down 
the Network Mapping process. The Network Mapping pro- 
cess also connects to the Configuration Server to obtain 
network, regional, site and device information needed to 
display the network maps at the user stations. The Network 
Mapping process also connects to the Authentication Server 
process to obtain a list of user-specific privileges, which 
represent valid functions available to a particular user. 

Another major process within the domain of the Operator 
Services component of the management system is the Site 
Control process. This process provides an number of distinct 
functions including providing a user interface for loading 
and updating, data received from external systems, for 
maintaining site level information, for issuing commands to 
network devices and for monitoring and transmitting a PDS. 
Thus, the Site Control process is comprised of six major 
subprocesses, including an IRD Management process, Site 
Management process, Command process, Macro process, 
PDS Manager process and SCP process. These subprocesses 
are described separately below. However, it will be under- 
stood that all of these processes fall within the Site Control 
process. 

The interfacing between the Site Control process and the 
other components of the management system is shown in 
greater detail in FIG. 10. The Top Level Menu process is 
responsible for initiating the Site Control process after a user 
has successfully logged on. The Site Control process regis- 
ters itself (including any of the relevant subprocesses) and 
any associated windows with the Process Monitor. The Site 
Control process is also connected to the Authentication 
Server to obtain a list of user-specific privileges, which 
represent the available functions for the particular user. The 
Site Control process requests information from the Configu- 
ration Server such as Site and IRD information. Updates to 
these objects are also accomplished through this connection. 
The Command Dispatcher receives commands from the 
Command process and directs the commands to the appro- 
priate destination device for execution. The Site Control 
process also communicates with the Command Dispatcher 
to maintain a list of valid freeform commands. The Site 
Control process is also connected to the Message Dispatcher 
to send messages to be logged to the database and displayed 
through the message windows in the Top Level Menu 
process. The Site Control process also requests information 
from the PDS Server such as network channel defaults, key 
index defaults, and SCPs. Updates to these objects can also 
be performed through this connection. The Site Control 
process also communicates with the Macro process to add, 
delete and update system macros. The Site Control process 
also communicates with the SCP Server to update a broad- 
cast schedule due to satellite circuit changes. 

A subprocess included in the Site Control process is the 
IRD Management process. This process provides a user 
interface to manage the network of IRDs. Within a selected 
Satellite Network, the IRD Management process provides 
the ability to make new IRDs available for use, load IRD 
software, extract IRDs from the network for resale, make 
deauthorized IRDs available for use, and delete IRDs from 
the particular Satellite Network. 

The IRD Management process comprises five major sub- 
processes. The first major subprocess is the loading of new 
IRDs. New IRDs may be added to the network, for example, 
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by loading them from a diskette received from the manu- search criteria related to a site which will then be used for 
facturer. The diskette may contain IRD serial numbers and selection purposes relative to the system databases. The 
other associated information and values. The second major Search subprocess also allows a user to view or print specific 
subprocess is the loading of IRD software. The IRD manu- site -related information based on the search criteria entered, 
facturer may provide IRD operating software on diskette 5 The second subprocess is the Site subprocess. This subpro- 
each time the software is upgraded. This software may be C ess allows the installation of new sites to the database with 
downloaded to the IRDs over one or more Satellite Net- assigned and authorized IRDs. The Site subprocess may also 
works. A command window within the Operator Services a u ow a user t0 stack and add to the database a new problem 
component is responsible for retrieving the software version f or a particular site. Site problems may include, for example, 
from the server and initiating a software download com- 30 a situation in which an IRD is not receiving a signal or has 
mand to upgrade the IRDs in the network. The third major crashed. In this case, a field technician may be assigned to 
subprocess is the reselling of IRDs. If a particular network fi x the problem and this activity can be tracked by the Site 
contains excess IRDs, these IRDs can be extracted from the subprocess. Another example is when an IRD is receiving 
network and resold back to the manufacturer or to other the wrong broadcast. The IRD may have drifted off its home 
customers. The fourth major subprocess is the moving of 15 channel In this case, a command may be sent to the IRD via 
IRDs to a pool designated as "available." Before an IRD is the management system. The Site subprocess may also be 
assigned to a particular site, it should be placed in the used to de-insUll a site from the network. This results in the 
"available" pool. For example, if an IRD was previously deauthorization of IRDs from the site and all site-related 
deauthorized and subsequently fixed, an operator may wish d a t a is deleted from the database. Preferably, no historical 
to make the IRD available for use by moving it from a 20 information is maintained. However, the system may be 
"deauthorized" pool to the "available" pool. The fifth major configured to save selected historical information. The Sat- 
subprocess is the deletion of available IRDs. For example if e nj le circuit subprocess provides several functions. First, a 
an IRD was mistakenly loaded into the network from a new satellite circuit may be added to the database. Prefer- 
manufacturer's diskette, it may be removed or deleted from a bly each satellite circuit is identified by a name, 
the network through this subprocess. These five major 25 description, and at least one key index. A key index can 
subprocesses of the IRD Management process may be generally be described as a unique number assigned to a 
performed by an operator through the user interface avail- particular slot in an IRD. Each defined key index should 
able within the Operator Services component and by way of have a network level defaulted service authorization mask 
retrieval and updating of data obtained through the Con- ("SAM"), key tag, program key ("PKey"), and PTM. All of 
figuration Server. 30 these values may be updated by the user. The Satellite 
The interfacing of the IRD Management process with Circuit subprocess may also be used to copy and/or add a 
other processes within the overall management system is satellite circuit definition to the database under a user- 
shown in greater detail in FIG. 5. The IRD Management provided new satellite circuit name and description. The 
process is preferably initiated by a user through the Top Satellite Circuit subprocess may also be used to update a 
Level Menu process after the user has successfully logged 35 satellite circuit definition within the system databases. The 
on. The IRD Management process registers itself and any of satellite circuit description and the number of key indices 
its associated windows with the Process Monitor which can defined may be updated by a user. Additionally, the user 
then process any user-generated IRD Management requests. should be able to update any key index parameters such as 
The IRD management process also connects to the Authen- the SAM, key tag, PKey, and PTM. The Satellite Circuit 
ticalion Server process to obtain a list of user-specific 40 subprocess may also be used to rename a satellite circuit 
privileges. The IRD Management process requests configu- within the database. This subprocess may further be used to 
ration information from the Configuration Server such as delete a satellite circuit from the database. This subprocess 
"deauthorized" and "available" IRDs. Updates to this infor- may also be used to assign an identifier label to a bit position 
mation are also performed through this connection. The IRD within the PTM for a specific key index within a specific 
Management process is also connected as a client process to 45 network. 

the Message Dispatcher process. The IRD Management Th e interfacing between the Site Management process 

process also interfaces with the Program Data Stream Server an d the remainder of the management system is shown in 

("PDS Server"). Through this connection, the IRD Manage- greater detail in FIG. 6. As with several other processes, the 

ment process can validate IRD software versions. Updates to Top Level Menu process is responsible for initiating the Site 

IRD software versions may also be performed. 50 Management process. The Site Management process regis- 

Another subprocess within the Site Control process is the ters itself and any of its associated windows with the Process 
Site Management process. The Site Management process Monitor. The Site Management process also is connected to 
provides a user interface to manage network-specific site the Authentication Server process to obtain a list of user- 
data by performing all changes to sites, site equipment and specific privileges. This list includes specific privileges for 
site related data in a predetermined, controlled manner. The 55 Site Management access. The Site Control process requests 
Site Management process preferably allows a user to search configuration information from the Configuration Server, 
for site and IRD information, install sites, track site prob- For example, the Site Management process may require site, 
lems and de-install sites. This process should also allow the IRD, encoder, and satellite circuit-related information, 
user to add, copy/add, update, rename, and delete the Updates to these objects are also performed through this 
satellite circuits. Also, the user can assign an identifier label 60 connection. Therefore, for the Site Management process, all 
to each bit position within a program tier mask ("PTM") for data requests, updates and deletions are handled by the 
a specific key index within a specific network. Further, a user Configuration Server. The Site Management process is also 
can install, swap and de-install IRDs from a site using the connected to the Command Dispatcher process. The Corn- 
Site Management process. mand Dispatcher receives authorization data stream 

The Site Management process comprises three major 65 ("ADS") and initialization macro command bundles from 

subprocesses. The first major subprocess is the Search the Site Management process and directs the commands to 

process. This subprocess allows a user to enter specific the appropriate Device Interface within the External Inter- 
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face 3 component for execution. The Site Management 
process is also connected to the Message Dispatcher process 
and sends messages there to be logged on the database and 
displayed through message windows within the Operator 
Services component. The Site Management process also 5 
notifies the PDS Server when a satellite circuit has been 
updated. This action triggers the PDS Server to recalculate 
the PDS PTM for any scheduled or active Satellite Circuit 
Plan ("SCP"). The Site Management process communicates 
with the Macro Server process to obtain and validate the 10 
network-specific initialization macro. The macro commands 
are bundled and executed through the Command Dispatcher 
as described above. 

Another subprocess within the Site Control process is the 
Command process. This process provides a user interface for 15 
executing device commands, maintaining freeform com- 
mands and receiving encoder status information. The Com- 
mand process allows an operator to issue specific commands 
to the various devices within the network. An operator may 
select a command category (e.g., based on the destination 20 
device) and may select from a list of commands applicable 
to the destination device. The operator can then complete the 
command by choosing from a list of parameters and by 
choosing a destination. Valid parameter values for IRDs and 
encoders may be predetermined and preset, for example, by 25 
the manufacturer of the IRD or encoder. The Command 
process can validate the user-entered parameters against the 
predefined valid values. 

Examples of devices that can receive commands include 
IRDs, data expansion units ("DEUs"), encoders, and Video 30 
Cassette Recorders ("VCRs"). Commands to all devices are 
initially sent to at least one encoder, but commands sent to 
devices other than encoders do not have the designated 
encoder as the command's final destination. Thus, the com- 
mand types are preferably classified according to their final 
destination device. 

The Command process should also enable the user to 
define commands that are not predefined within the man- 
agement system. These commands are called, for example, 4Q 
"freeform" commands. The available commands should at 
least include predefined commands for encoders, IRDs, 
DEUs and VCRs. The available commands should also 
include freeform commands for each of these devices. Other 
available commands should include "IRD add teletext," 45 
"IRD remove teletext," and "IRD software download" com- 
mands. In certain cases, a single logical command may be 
used to include several separate device commands. 

In the case of the IRD, DEU and VCR commands, a user 
can select one or more encoders in order to direct the 50 
command. Preferably, the user chooses a device destination, 
such as an individual IRD address in the network, a group 
of IRDs specified by a key index and PTM value, or all 
IRDs. In the case of encoder commands, the user should 
only be able to select one encoder as the destination for the 55 
command. 

Predefined commands should be available on the data- 
base. Freeform commands should be able to be saved to the 
database for execution at a later date and/or time. An access 
security level should be associated with each command type $0 
and also with each destination device. For example, the 
more powerful the command type the higher the access 
privilege. Commands are sent via the Command Dispatcher 
to the appropriate Device Interface. 

The interfacing of the Command Process with the remain- 65 
der of the management system is shown in greater detail in 
FIG. 7. The Top Level Menu process is responsible for 
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starting the Site Control process which includes the Com- 
mand process. The Command process registers itself and 
any associated windows with the Process Monitor. The 
Command process also connects to the Authentication 
Server process to obtain a list of user-specific privileges 
representing the valid functions available to the particular 
user. The Command process request configuration informa- 
tion from the Configuration Server such as IRD data. The 
Command process validates such information as IRD serial 
numbers entered by the user through this connection. For 
example, the Command process should determine whether a 
particular IRD serial number designated as the destination 
device exists within the database, whether the IRD serial 
number is "authorized" for the selected network (e.g., sat- 
ellite network), and that the IRD serial number is not 
authorized for a different network. The Command process 
also receives the channel for a specific IRD serial number in 
order to properly select the appropriate encoder destination 
through which the command to the IRD will be sent. This 
structure is similar for DEUs and VCRs. 

The Command Dispatcher receives commands sent from 
the Command process and directs commands for execution 
to the appropriate Device Interface within the External 
Interfaces component. The Command Dispatcher also sends 
a command result indicating success or failure back to the 
Command process. The result should indicate the success or 
failure of the command being sent to the device and not the 
actual success or failure of the execution of the command. 
For encoder commands, a response may also be returned to 
the Command process from the Device Interface process via 
the Command dispatcher. The Command process also com- 
municates with the Command Dispatcher to maintain a list 
of valid freeform commands. The Command Dispatcher 
maintains freeform commands by reading and/or writing the 
commands from and to the system database. The Command 
process is also connected to the Message Dispatcher pro- 
cess. The Command process sends messages to the Message 
Dispatcher to be logged to the system database and dis- 
played through message windows within the Operator Ser- 
vices component. The Command process sends a message to 
the Message Dispatcher that details each command that is 
sent. Through a command window, a user can request all the 
known software versions from the PDS Server. This infor- 
mation is presented to a user when the user chooses to send 
an IRD software download command and wishes to choose 
the software version for the command by picking from a list. 
The Command process also communicates with the Macro 
Server process when the user attempts to delete a freeform 
command. 

Another subprocess within the Site Control process is the 
Macro process. The Macro process provides a user interface 
to maintain and control the execution of command macros. 
A command macro consists of one or more commands 
grouped together to perform a logical function or a logical 
group of related functions when executed. Preferably, the 
Macro process allows macros to be manipulated through 
several user actions. These actions can be initiated by the 
user through a macro manager window which is accessed 
from the Top Level Menu process by choosing the Macro 
process and then the macro management window. The user 
has the ability to begin the creation of a new macro, copy an 
existing macro, delete a macro, rename an existing macro, 
edit an existing macro, schedule a macro for execution, or 
immediately execute a macro. With respect to scheduling, a 
user can schedule a macro to begin execution at a particular 
date and time and can specify if the macro is to be executed 
once or periodically. Macros are preferably classified as 
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"pending," "executing," or "completed." Preferable, a user 
can manipulate "pending" macros by placing a scheduled 
pending macro on hold, releasing a held macro, editing a 
pending macro, viewing the steps for the macro, and can- 
celing the macro. With respect to "executing" macros, a user 
should be allowed to place the "executing" macro on hold, 
release a held macro, view the steps for the macro, view the 
execution status for the steps of the macro, or cancel the 
macro. With respect to "completed" macros, a user should 
be allowed to view the steps for a "completed" macro or a 
canceled macro, view the execution status of each step of the 
macro, and acknowledge or delete the macro. 

The interfacing of the Macro process with the remainder 
of the management system is shown in greater detail in FIG. 
8. The Top Level Menu process is responsible for initiating 
the Macro process. The Top Level Menu process initiates the 
Macro process after a user has successfully logged on. 

The Macro process registers itself and associated win- 
dows with the Process Monitor. The Macro process also 
connects to the Authentication Server process to obtain a list 
of user-specific privileges. The Macro process requests 
configuration information from the Configuration Server. 
Such information can include, for example, IRD data. For 
instance, the Macro process can validate IRD serial numbers 
entered by a user through this connection. The Macro 
process also should be able to receive the channel for a 
specific IRD serial number in order to preselect a proper 
encoder destination. 

The Macro process communicates with the Command 
Dispatcher to maintain a list of valid freeform commands. 
The Command Dispatcher maintains freeform commands by 
reading and/or writing the commands from and to the system 
database. The user can save, replace and delete freeform 
commands. 

The Macro process is connected as a client to the Message 
Dispatcher process. The Macro process, through its associ- 
ated windows, sends messages to the Message Dispatcher to 
be logged to the system database and displayed through 
message windows within the Operator Services component. 
Preferably, the Macro process sends a message to the 
Message Dispatcher each time a macro is scheduled or 
executed. The Macro process also sends a message to the 
Message Dispatcher for each event that the user initiates. 

The Macro process requests all the known software 
versions from the PDS Server. This information is presented 
to the user when the user chooses to assign a macro step for 
an IRD software download command and wishes to chose 
the software version or the command by picking from a list. 

The Macro process communicates with the Macro Server 
to receive, maintain (save, edit and delete), schedule and 
execute macros. A macro schedule or window receives the 
status of pending, executing and completed macros through 
communication with the Macro Server. 

Another subprocess within the Site Control process is the 
Satellite Circuit Plan process ("SCP process"). The SCP 
process provides a user interface to manage a network SCP 
(e.g., a broadcast schedule). Preferably, this is accomplished 
on a monthly basis. The SCP process provides the ability to 
create a new SCP by loading a schedule from a floppy disk, 
manually building a new SCP, or updating/deleting an 
existing SCP. The SCP process is comprised of three major 
subprocesses. The first major subprocess is the Load SCP 
subprocess. This subprocess allows a broadcast schedule to 
be loaded from a floppy disk for the network. It can load a 
broadcast schedule for any network for as long as the input 
file follows a specific format. The second major subprocess 



is the Build New SCP subprocess. This subprocess provides 
the ability to manually create a broadcast schedule for any 
network. The third major subprocess is the View/Update 
SCP subprocess. This subprocess allows an operator to 
5 review or modify existing broadcast schedules for any 
network. 

Preferably, a network customer will provide a broadcast 
schedule to the operator of the management system each 
month. The broadcast schedule can be included on a floppy 
10 disk. The schedule should indicate the broadcast channel, 
schedule, start and end times., and the satellite circuits that 
should receive the broadcast. Preferably, the management 
system operator transmits the schedule to the destination 
devices within the designated satellite circuits by way of the 
PDS Manager and PDS Server. Preferably, the schedule field 
on the input file is represented in terms of days of the week 
as opposed to actual calendar dates. Before a schedule can 
be used by the PDS Manager and transmitted by the PDS 
Server, it should be translated into actual calendar dates and 
stored on the database. 

Broadcast files can generally be edited and converted into 
calendar dates in one of at least two ways. For example, the 
conversion may be by "generated input." According to this 
method, the input schedule as it appears on the floppy disk 
is displayed to the operator for review. After all changes are 
made to the schedule, it is sent to the SCP Server where it 
is converted into calendar dates. This option reduces the 
amount of information that the operator needs to review, 
reduces the amount of network traffic, and places the load on 
the SCP Server to create SCP output records. Conversion 
may also be accomplished by "generated output." According 
to this method, the input schedule is translated into calendar 
dates and displayed to the operator for review. After all 
changes are made to the schedule, it is sent to the SCP Server 
where it is stored on the database. This option provides the 
ability to review the converted SCP outputs but greatly 
increases the amount of information that must be reviewed 
by the operator and the amount of network traffic. 
Preferably, the operator specifies the time period that the 
SCP will span. By specifying a date and time for start and 
a date and time for end, SCP output records will be gener- 
ated for each specified week day during the specified time 
period. 

Preferably, each input record is validated before SCP 
output records are generated. As part of the validation 
process, a specified channel must be defined for the specified 
network. Also, the schedule should equal "MWF" (Monday, 
Wednesday, Friday) or "TTSS" (Tuesday, Thursday, 
Saturday, Sunday). Start times and end times should be, in 
the form of valid military times. Also, satellite circuits 
specified on the input record must be those defined to the 
network. 

When processing a floppy disk SCP received from a 
network customer, the management system operator will 
have several options to deal with satellite circuits which art 
not defined to the network. Among these options, the man- 
agement system operator can ignore the undefined satellite 
circuit, add a satellite circuit to the network, or replace each 
occurrence of the undefined satellite circuit with another 
already defined satellite circuit on the network. According to 
another feature, if an overlapping schedule entry already 
exists on an SCP, the operator will have the option to ignore 
the duplicate entries or delete the overlapping entries. 

The satellite circuits specified for each input record are 
used to calculate the PDS PTM. The PDS PTM is transmit- 
ted as part of the PDS command by the PDS Server. The 
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PDS command contains encryption and decryption informa- The last subprocess within the Site Control process is the 

tion used by IRDs within the designated satellite circuits to PDS Manager process. This process uses data from the SCP 

determine if they are authorized to receive the broadcast to create the program data stream and transmit it to the IRDs. 

being transmitted. The PDS PTM is calculated by adding the The PDS is transmitted by date, time and channel to the 

ADS PTMs (by key index) for each satellite circuit on the 5 irqs through the encoders. The SCP contains a list of valid 

input record. For example, if a schedule entry indicates that satellite circuits for a particular date, time and channel. The 

satellite circuits AAA and BBB are authorized to receive a PD s Manager process reads the SCP and creates the PDS for 

specific broadcast on channel 1 at 9:00 each MWF, this each channelj date and lime based on default information 

process will calculate the PDS PTM as follows: First, the defined fof a ne twork-specific channel (e.g., key index). The 

process will obtain a key index associated with channel 1. _ Dri0 _ • j *,u~ „ui:«„ * rt ~ ' „i 

Second, the process will find the ADS PTM for that key 10 ™5 ™ ana S er P r0vldes he abUll y t0 ^art, pause and stop the 

index for satellite circuits AAA and BBB within the satellite ™ S tranamssion. It ako provides the ability to override 

circuit ADS class. Third, these two values will be added to de ^ ^formation. Information such as key index, SAM 

obtain the PDS PTM. The PDS PTM is calculated for each and P J^y can be modified for a particular channel. Because 

input or output displayed to the user based on the network tne PDS Manager process is a subprocess of the Site Control 

defaults and the ADS PTM values at the time the window is 15 process, the interfacing of the PDS Manager with the 

displayed. remainder of the management system can be understood 

When creating a new SCP through the Load or Build from FIG - f °- Also, the PDS Manager process is described 

subprocesses, the operator has the option of creating a set of m connection with other management system processes 

special scheduled entries. This set of scheduled entries is below. 

referred to as the SCP defaults. The management system 20 Another major process of the Operator Services compo- 

may be configured such that the default entries are auto- nen t of the management system is the Process Manager 

matically generated when a new plan is created. This feature process. This process provides a user interface for starting, 

reduces the amount of repetitive data entry required by an stopping and monitoring the status of all management sys- 

operator when creating a new plan. tem pr0 cesses. This process is preferably configured to 

After an operator has reviewed and modified an SCP, the 25 operate from any management system node so long as a 

SCP can be saved to the database. As each generated output graphic user interface is available at that node. The Process 

record is saved to the database, any duplicate schedule Manager obtains and displays information contained in the 

entries will be deleted from other SCPs within the network. Process Monitor. 

The subprocess which permits the building of new SCPs n c , , 4 , n x . « . c 

•j , • 4 r . to c Preferably, the Process Manager displays information 

provides the ability to manually create an SCP for any 30 . , i_ . • 4 . * ; ^ 

r A •* j ,c j a it_ 1 a . about each node in the management system, the processes 

satellite circuit defined to the network. An operator can . 4 « - . 1 i_ * • *• u 

1 . j j 1 , i j 1 . . . C.™ . . running at each node, and general characteristics about each 

create, update and delete schedule entries in the SCP output , 0 Tt , 0 ., . r • , .% 

c I rSi . ,.rc i_ . t_ such process. It also provides information about the 

format. The main difference between this subprocess and the * l- l .l j lL 

. „ ... - „™ . *\ . . „ ... processes, the services which they provide and the connec- 

process which allows loading of SCPs is that in the Build f. , . 

kt or-n u . f a * ♦ 11 tl0ns between them. 

New SCP subprocess, output records are not automatically 35 

generated from SCP input records. Rather, they must be 7116 interfacing between the Process Manager and the 
created one at a time. However, as with the Load SCP remainder of the management system is shown in greater 
subprocess, SCP defaults may be generated. According to detail "> FIG - U - ^ Process Manager is preferably a user 
the View/Update SCP subprocess, an operator can view, interface which connects to a ROOT Process Monitor to 
update or delete an existing SCP. Under this subprocess, the 40 receive P rocess status information. Typically, this informa- 
operator can view a list of all SCPs defined to the network. tion should onl y be available to an administrator who can 
From the fist, the operator may select an SCP and view or ^ requests to the Process Monitor via the Process Man- 
update the SCP. Thus the operator can create, update and a 8 er t0 start > st0 P or u P date ^dividual processes or shut 
delete schedule entries in the SCP output format. When all down the entire management system, 
updates have been complete and the operator saves the plan 45 m Management Services 
to the database, only the updated records should be sent to 

the SCP Server and updated on the database. The second major component of the management system 

The interfacing of the SCP process with the remainder of * the Management Services component. This component 

the management system is shown in greater detail in FIG. 9. acts «s the interim step between the user interfaces within the 

The Top Level Menu Process is responsible for initiating the 50 Operator Services component and the device and external 

SCP process after a user has successfully logged on. The system interfaces within the External Interfaces component. 

SCP process registers itself and its associated windows with n& Management Services component includes, for 

the Process Monitor. The SCP process also connects to the example, the Message Dispatcher process, Configuration 

Authentication Server process to obtain a list of user-specific Server process, Macro Server process, PDS Generator 

privileges. The SCP process request configuration informa- 55 process, SCP Server process, Command Dispatcher process, 

tion from the Configuration Server such as network defaults Process Monitor process, and Authentication Server process, 

and satellite circuits. The SCP process is also connected as The Message Dispatcher, as described above, receives 

a client process to the Message Dispatcher process. The SCP informational messages from the other processes in the 

sends messages to the Message Dispatcher to be logged to management system. These messages are routed to the 

the database and displayed through message windows within 60 various users who are logged onto the system. The Message 

the Operator Services component. The SCP process also Dispatcher also logs the messages to the system database for 

obtains calculated PDS PTM values and other information storage. Messages are also received from the management 

necessary for creating an SCP through its connection to the system itself and from the Process Monitor. Thus, the 

PDS Server. The SCP process communicates with the SCP Message Dispatcher servers as a central repository for 

Server to save new SCPs to the database. Updates or 65 informational and system messages, 

deletions of existing SCPs are also performed through this The interfacing between the Message Dispatcher and the 

connection. remainder of the management system is shown in greater 
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detail in FIG. 12. The Process Monitor is responsible for 
initiating the Message Dispatcher, monitoring its status and 
shutting it down upon request. This interface supports these 
operations using a system-wide class from which the Mes- 
sage Dispatcher inherits. The Process Monitor also sends 5 
system messages to the Message Dispatcher. Preferably, the 
Message Dispatcher acts as a server to any other process in 
the management system which needs to create or receive 
informational or system messages. Messages are requested 
by other process via a remote procedure call ("RPC"). This 10 
call is preferably asynchronous, so that clients do not have 
to wait for the call to be completed before they continue 
processing. Each message inserted into the object model is 
automatically assigned a time stamp and is written into the 
system database. is 

Another major process of the Management Services com- 
ponent is the Configuration Server process. The Configura- 
tion Server functions as the repository of network data 
describing all managed objects, including all processes and 
devices. Network data reflects the current state of the entire 20 
network. The Configuration Server gathers data from other 
processes. It then adds, updates and deletes network data on 
persistent storage (the management system database). Infor- 
mation is then distributed to any process requesting it on an 
as-needed basis. 25 

The types of information maintained on the Configuration 
Server can be divided into three classes including network 
inventory, network state, and application reference data. 
Network inventory is largely static data relating to, for 
example, site and network devices, countries, regions, 30 
networks, encoders, channels, satellite circuits and IRDs. 
Network state is dynamic data which includes current net- 
work and device status information. Application reference 
data includes satellite circuit plans, IRD measurements, and 
command execution schedules. 35 

Preferably, there are at least two basic ways in which the 
Configuration Server receives and distributes data. The first 
way is a passive method as the remote process updates or 
receives data from the Configuration Server. The second 4Q 
way is via an remote process call function. In this latter case, 
the remote process must invoke the RPC to request the 
Configuration Server to update or distribute data. For 
example, the Site Management process may use an RPC 
function to update the "site problem status" of the Configu- 45 
ration Server, while the Site Management process uses 
another RPC to ask for IRD data. 

The interfacing of the Configuration Server with the 
remainder of the management system is shown in greater 
detail in FIG. 13. The Configuration Server registers itself 50 
with the Process Manager, thus allowing other processes to 
communicate with the Configuration Server. When the Pro- 
cess Manager starts the Configuration Server, the Configu- 
ration Server initializes its in -memory database with data 
from the system database. When the Process Manager shuts 55 
down the Configuration Server, an RPC function can be used 
to request the Configuration Server to write changed net- 
work inventory data to the system database. The Configu- 
ration Server provides the network configuration data to the 
Network Mapping process, the Message Dispatcher process, 60 
the SCP Manager, the SCP process, the Site Control Process, 
the Device Interfaces, the Command process, the Macro 
process, the IRD management process and all other appli- 
cable processes within the management system. 

Another major process within the Management Services 65 
component of the management system is the Macro Server. 
This process is responsible for storing and maintaining 
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macros, scheduling macros for execution, sending the com- 
mands contained in each micro step to the Command 
Dispatcher for execution, and monitoring execution of all 
macros. The Macro Server serves as the distributor for all 
macro data which is contained in the system database and as 
the manager of all macro scheduling and execution. A user 
process can make a request to the Macro Server to get all the 
macros for a particular network. User processes can also 
make requests (e.g., copy, replace, save, delete, schedule and 
execute) to be performed on the macros and their individual 
steps. 

Preferably, macros that are scheduled for execution are 
queued and await their respective execution times. Sched- 
uled macros are maintained in memory and also written to 
the database as a backup. If the Macro Server is stopped for 
any reason, it should load all scheduled macros back into the 
queue from the database when it restarts. When the time 
comes for execution of a macro, each step is sent in turn to 
the Command Dispatcher. A previous step must execute 
before a subsequent step is sent for execution. The Macro 
Server is preferably capable of pausing, releasing from a 
previous pause or canceling a macro before execution or 
during the macro's execution, when requested by a user. The 
Command Dispatcher routes the commands and returns the 
results to the Macro Server. Appropriate informational mes- 
sages are preferably generated and sent to the Message 
Dispatcher. 

The interfacing of the Macro Server with the remainder of 
the system is shown in greater detail in FIG. 14. The Macro 
Server interfaces with the Process Monitor which starts the 
Macro Server, creates service connections between the 
Macro Server and other compatible processes, and shuts 
down the Macro Server when requested. The Macro Server 
interfaces with the Top Level Menu process by allowing a 
user to access (within a window environment) all existing 
macro names for a specific network from the Macro Server. 
The Macro Server receives macro line requests from a user 
through appropriate windows. These requests include 
retrieve, save, add, edit, copy, delete, execute and schedule. 
The Macro Server interfaces with the Command Dispatcher 
by sending all macro command steps thereto. Completed 
commands marked with a success or failure indicator are 
returned back to the Macro Server from the Command 
Dispatcher. Appropriate informational messages are for- 
warded from the Macro Server to the Message Dispatcher. 
The Macro Server interfaces with the Configuration Server 
by gathering startup device data such as networks, encoders, 
IRDs and channels. The Macro Server interfaces with the 
system database by gathering from the system database all 
scheduled and completed macro data during startup. Sched- 
uled and completed macros and their current status are saved 
to the system database when the Macro Server is shut down. 

Another major process within the Management Services 
component of the management system is the Program Data 
Stream Generator ("PDS Generator"). The PDS Generator is 
responsible for scheduling and releasing the PDS, sending 
the PDS by channel to the Command Dispatcher for 
execution, and monitoring the execution of the PDS. The 
PDS Generator thus serves as the central repository for all 
schedule (e.g., monthly SCP) data as well as channel and 
key index default data. This information is loaded from the 
system database when the PDS Generator process is started. 
This information is used by the PDS Generator to create the 
PDS, The PDS Generator also maintains information for 
scheduling changes to default data used to create the PDS. 
An issued PDS command request may be sent to the 
Command Dispatcher for each network channel. The PDS 
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command requests are continually sent to the Command Another major process within the Management Services 
Dispatcher based upon a predetermined interval. A com- component of the management system is the Command 
pie ted command marked with a success or failure indicator Dispatcher process. The Command Dispatcher is primarily 
is received from the Command Dispatcher for each issued responsible for issuing commands to a specific device inter- 
command. Appropriate informational messages are gener- 5 face for execution on the appropriate destination device and 
a ted based on PDS status and/or error conditions. The PDS for reporting success or failure of the execution. This 
Generator communicates with the PDS Manager to display process also allows distribution of all command types for 
information pertinent to the PDS currently being transmit- requesting processes and maintains freeform commands, 
ted. Update requests are received from the PDS Manager to Thus, the Command Dispatcher serves as the central dis- 
update default configuration data or to schedule updates to patcher for device commands and as a repository for free- 
the default configuration data. form commands. 

The interfacing of the PDS Generator with the remainder Command types are loaded from the system database 

of the management system is shown in greater detail in FIG. when the Command Dispatcher process is started. These 

15. The PDS Generator interfaces with the Process Monitor command types can be received from other processes (e.g., 

which starts the PDS Generator, creates connections Site Control, Macro Server, PDS Generator and Device 

between the PDS Generator and other applicable processes, 15 Interface). Requests can be made to the Command Dis- 

and shuts down the PDS Generator when requested. An patcher to save, replace and delete freeform commands. As 

interface also exists with the Command Dispatcher which previously discussed, the Site Control, PDS Generator and 

receives all PDS command requests from the PDS Genera- Macro Server processes make requests to send commands 

tor. Appropriate informational messages are sent to tie through the Command Dispatcher to target devices for 

Message Dispatcher. An interface also exists with the Site 20 execution. A command is sent by the Command Dispatcher 

Control process which obtains startup information such as to a specific Device Interface depending upon the destina- 

SCPs and default PDS data. The PDS Generator receives tion device. A completed command is marked with a success 

PDS line requests from the Site Control process including or failure indicator and is returned from the Device Interface 

start, stop, pause, view and edit channel defaults. The PDS to the Command Dispatcher. Completed commands and 

Generator receives requests to update or schedule updates to 25 their respective indicators are then returned to the originat- 

the PDS data from the Site Control process. An interface ing process with the management system, 

also exists with the system database from which the PDS The interfacing of the Command Dispatcher with the 

Generator obtains PDS startup data. PDS status and PDS and remainder of the management system is shown in greater 

SCP data are logged to the system database from the PDS detail in FIG. 17. The Command Dispatcher interfaces with 

Generator. 30 the Process Monitor which starts the Command Dispatcher, 

Another major process of the Management Services com- creates service connections to other appropriate processes, 
ponent of the management system is the SCP Server process. a nd performs shutdown when requested. The Command 
The SCP Server has at least two main purposes. First, this Dispatcher also interfaces with the individual Device Inter- 
process handles all database interactions dealing with the faces ^ Device Interfaces register each device with the 
SCP. Second, this process signals the PDS ^Server -to update Command Dispatcher to receive commands. The Device 
its linked Lists based on the changes made to the system Interfaces also dorm calls lhrou ^ the Command Dis- 

database. With respect to database interactions, the SCP is . . . t „ *u a * t j j 

r , . t j *i_ , i.i . t , , patcher to get all the command types. Issued commands are 
preferably stored on the system database in three tables r iiL • * t-* • t * * c . . . 
including the Control table, the Output table, and the Circuit < he a PP ro P™ te De ™ e In f fa f for execution based 
table. The Control table preferably contains high-level SCP on the destination device. Completed commands and indi- 
information such as control ID, label, start and end times, 40 cators are returned to the Command Dispatcher from the 
and network name. The Output table preferably contains Device Interface. The Command Dispatcher also interfaces 
scheduled outputs including SCP control ID, exact time of ^th the Site Control process, which performs startup calls 
the broadcast, and group ID of the satellite circuits that the 10 S et tne various command types and freeform commands. 
SCP will be broadcast on. The Circuit table preferably The Control process, through appropriate windows, sends 
contains the satellite circuit group ID and all the satellite 45 command requests to the Command Dispatcher. An interface 
circuits which belong in that particular group. SCP in for- also exists with the PDS Generator, which performs startup 
mation may be saved, deleted, modified and obtained by a calls to get the various command types. The Command 
user. Preferably, the PDS Server is triggered to modify its Dispatcher receives command requests from the PDS Gen- 
linked list of current PDSs going out when changes are made erator and forwards them to the appropriate Device Inter- 
to the SCP. Therefore, the SCP process must be able to 50 face. A° interface also exists with the Macro Server. This is 
recognize potential changes and call the appropriate RPC similar to the previous interfaces. 

functions on the PDS Server to check its internal linked lists. Another major process within the Management Services 

The interfacing between the SCP Server and the remain- component of the management system is the Process Moni- 

der of the management system is shown in greater detail in tor process. The Process Monitor monitors and controls all 

FIG. 16. The Process Monitor is responsible for starting the 55 management system processes. It starts and stops all server 

SCP Server, monitoring its status, and shutting it down. This and client processes. It can resolve requests forwarded from 

interface supports these operations using a system-wide other processes and can terminate any system process upon 

class from which the SCP Server inherits. The SCP Server request. 

connects to the Message Dispatcher to send appropriate The Process Monitor is a server process with no visual 

informational messages to be logged to the system database 60 component that simplifies the task of starting, stopping, 

and to be displayed to users. An interface exits with the locating and monitoring all processes within the manage- 

Configuration Server from which data is obtained such as ment system. There should be one and only one Process 

networks, network defaults and satellite circuits. The SCP Monitor for each node in the network. One Process Monitor 

Server notifies the PDS Server when its linked lists must is designated as the ROOT Process Monitor and all other 

change. The SCP Server receives requests from the Control 65 Process Monitors connect to it to create a hierarchy of 

process to retrieve, update, delete or save SCPs to the system Process Monitors. The Process Monitors within this hierar- 

database. chy communicate with each other to resolve requests. 
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Each Process Monitor is responsible for monitoring the information and to handle requests from an adminstrator to 

processes running at its respective node. All known pro- process inquiries and updates to the authentication informa- 

cesses are collected and forwarded to the ROOT Process tion. The Authentication Server is started and stopped by the 

Monitor. This special monitor knows about all processes Process Manager, 

running within the entire network. If all application pro- 5 

cesses run on the same node in the network, only one IV. External Interfaces 

Process Monitor (ROOT) can be active since only one ^ Mtd&CGS component of the man agement 

Process Monitor exists on a node. system ^ ^ thifd major componem and includes all device 

When the Process Monitor is launched, a command line interfaces and interfaces with any external systems, 

parameter specifies a file containing a list of processes that 10 p referablVy interfacing with any network device is accom- 

it must start on the same node that the Process Monitor is plished through an initial connection with one or more 

running. The Process Monitor is responsible for monitoring encoders. However, the system may be configured to incor- 

this list of processes and uses this list to start all other porate direct interfacing with devices other than encoders. 

management system processes in the correct order. „ . . , - , . , , . #u 

& J r . 1<; For example, an interface can be provided with an 

Each system process preferably ^ues a heartbeat at a encoder associated with a particular broadcast. As discussed 

specified predetermined interval. If the Process Monitor above> commands t0 destination dev ices within one or more 

does not receive a heartbeat from a process within a specific sa , elli , e aetW0[is may be xat via lhe Command Dispatcher 

threshold, it will assume the process is dead and prevent , h fa ^ inlerface and forwarded l0 the a pp rop riate 

further communication with the process. In this case a device& devices m prefcrab ,y id6n[ified by various 

process can be killed and automatically restarts through the crjteria residi Qn , he m da , abase and/of on one or 

Process Monitor service If the Process Monitor dies, all more of the Kr/m the Management Services com . 

other processes on the node become inactive and the Process CO nent 

Monitor must be restarted. _ . '. .... . -i.j-j.i- 

„ .... . . . This invention has been described in detail in connection 

The Process Monitor also manages the graphic user ^ ^ ferfed em5odiments . However, these embodi- 

interfaces. TTus fraction allows a user interface for a par- meQls are ided of k Qn[ u ^ be 

ticular apphcation to be distributed among several chent underetood b those havin ordin skm in the rtinent ^ 

processes. Each logged user is assigned to a session. That ^ modific / tions and ch a to the tems ^ described 

session contains as many processes as needed to make up a be m ^ d ^ frQm ^ ^ ^ Qf 

complete instance for the user interface for an apphcation. ^ invention as defined b tne appended claims. For 

The Process Monitor allows processes cooperating in a { mQre tQan Qne ^ tem ma be 

session to pass messages back and forth. For example, one vided withifl a telecommunication network. The multiple 

process may request another process in the session to display emem lems be interfaced to provide increased 

a particular window M communication between processes { reliability and scalability. Also, the various com- 

is controlled through the Process Monitor. 35 ponents and pr()cess descfibed aboye may ^ dupHcaled and 

The interfacing of the Process Monitor with the remainder integrated within a management system to provide similar 

of the management system is shown in greater detail in FIG. advantages. 

18. The Process Monitor is a user interface process that j c i a i m: 

connects to the ROOT Process Monitor to receive process i A telecommunication system, comprising: 

status information so that this information can be displayed Art . , . . n t „„ om , t ^ r fnr t „ ncm ;t*; nn « 

. . . t t ™ . . . , t r J .40 a broadcast site having a transmitter tor transmitting a 

to a system administrator. The administrator can send , ° ° 

requests to the Process Monitor to shut down the entire program signa , 

management system or to terminate individual processes. an encoder operable to encode the program signal; 

Each process within the system interfaces with the Process a plurality of satellite circuits; 

Monitor and indicates to this process whether it is alive and 45 a plurality of integrated receiver/decoders for receiving 

well. the program signal, each integrated receiver/decoder 

Another major process within the Managment Services assigned to one of the plurality of satellite circuits; and 
component of the managment system is the Authentication a satellite for relaying the program signal from the broad- 
Server process. This process verifies user IDs and password cast site to each of the integrated receiver/decoders; 
information, controls access to various windows between 50 a nd wherein the encoder is further operable to receive a 
related user interface processes, and controls updates to the program command, the program command operable to 
database for authentication information. This process also cause a change in a configuration of a selected satellite 
has no visual component. c i rcu j t independently of a configuration of other satel- 

When the Authentication Server process is started by the lite circuits and a corresponding change in a configu- 

Process Manager, the Authentication Server connects with 55 ration ofthe integrated receiver/decoder assigned to the 

the system database. The Authentication Server maintains a selected satellite circuit. 

list of valid users and associated encrypted passwords. It 2. The telecommunication system of claim 1, wherein at 

verifies user ID and password information by performing a least two intergrated reciver/decoders are assigned to the 

one-way encryption on the received password and then selected satellite circuit, the program command is operable 

comparing the user ID and encrypted password to the list of go to cause a change in the configuration ofthe selected satellite 

valid users. The Authentication Server also maintains a list circuit, which causes a corresponding change in a configu- 

of operator roles, which consists of a predetermined named ration of each of the integrated receiver/decoders assigned to 

set of privileges. Each user ID is associated with a role. the selected satellite circuit independently of a configuration 

The interfacing between the Authentication Server and the of the other integrated receiver/decoders, 

remainder of the management system is shown in greater 65 3. The telecommunication system of claim 1 wherein the 

detail in FIG. 19. The Authentication Server serves the Top program command comprises a macro, the macro compris- 

Level Menu process to verify user ID, password and role ing a plurality of commands, each of the plurality of 
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commands changing a corresponding characteristic of the wherein the operator services component provides an 

selected satellite circuit. interface between the management system and a plu- 

4. The telecommunication system of claim 1, wherein the rality of operators, 

encoder is further operable to encrypt a portion of the wherein the management services component includes a 

program signal, and wherein each integrated receiver/ 5 plurality of servers to communicate with the operator 

decoder is operable to decrypt the encrypted portion of the services component and the external interface 

program signal. component, and 

5. The telecommunication system of claim 1, wherein the wherein the external interface component provides an 
program command is delivered to the selected satellite interface between the management services component 
circuit through an interface with the encoder. 10 and a plurality of external devices. 

6. The telecommunication system of claim 5, further 13 - ™? telecommunication system of claim 11 wherein 

comprising at least one other encoder, wherein the system is one ? f the P lurabt y of external devices comprises the 

adapted to reroute the program command through the at least . . * A . . . 4 r . . „ . 

th \ 14. The telecommunication system of claim 11 wherein 

one otner encoder. he luralit of exlen)al dev ices comprises the plurality of 

7. The telecommunication system of claim 1, further is mte £ rated receiver/decoders. 

comprising a management system operable to transmit the x | A method for managiag a telecommunication system, 

program command to the encoder, wherein the management comprising* 

system is adapted so that the program command is issued by transm i tt ing a program signal from a broadcast site to a 

an operator of the management system at a first time and is satellite* 

scheduled for execution on the selected satellite circuit at a 20 relaying m ' e prQgram sigQal frQm the sateUite iQ each of a 

second time, wherein the interval between the first and plurality of integrated receiver/decoders, each inte- 

second time is predetermined. grated receiver/decoder assigned to one of a plurality of 

8. The telecommunication system of claim 1, each inte- satellite circuits* and 

grated receiver/decoder having a plurality of slots, wherein transmitting a program command to an encoder coupled 

the program command causes a set of decryption keys to be 25 t0 me broadcast site, the program command operable to 

loaded into one of the plurality of slots. change a configuration of a selected satellite circuit 

9. The telecommunication system of claim 1, wherein an independently of a configuration of other satellite cir- 
execution of the program command is automatically per- cuits and a corresponding change to a configuration of 
formed according to a predetermined schedule. the receiver/decoder assigned to the selected satellite 

10. The telecommunication system of claim 1, wherein a 30 circuit. 

plurality of program signals are transmitted to each of the 16. The method of claim 15, wherein at least two inter- 
plurality of satellite circuits, and wherein the encoder is grated reciever/decoders are assigned to the selected satellite 
operable to encode each of the plurality of program signals. circuit, wherein transmitting the program command is fur- 

11. A telecommunication system, comprising: her operable to change a configuration of all the receiver/ 
a broadcast site having a transmitter for transmitting a 35 decoders assigned to .the selected satellite circuit. 

program signal and an encoder for encoding the trans- 11 ' ™ e method of claim 15 > filrther uprising: 

mitted program signal; encrypting a portion of the program signal using the 

. c , . encoder prior to transmitting the program signal to the 

a plurality of satellite circuits; sateUite; and s * 

a plurality of integrated receiver/decoders, wherein each 4Q d ti the encrypted portion of the program signal 

of the receiver/decoders is assigned to one of the . tfae receiver/decoderSt 

plurality of satellite circuits; 18 The method of claim 15> wherem ^^t^ the 

a satellite for relaying the program signal from the broad- program command is further operable to load a set of 

cast site to each of the plurality of satellite circuits; and decryption keys into one of a plurality of slots of the 

a management system operable to change a configuration 45 receiver/decoder assigned to the selected satellite circuit, 

of a selected satellite circuit independently of a con- 19. The method of claim 15, wherein transmitting the 

figuration of other satellite circuits and a corresponding program command is further operable to assign another 

change in a configuration of the receiver/decoder receiver/decoder to the selected satellite circuit, 

assigned to the selected satellite circuit by transmitting 20. The method of claim 19, wherein transmitting the 

a program command to the encoder. 50 program command is further operable to delete one of the 

12. The telecommunication system of claim 11, wherein receiver/decoders assigned to the selected satellite circuit 
the management system comprises an operator services from the selected satellite circuit. 

component; a management services component and an 

external interface component, * * * * * 
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